写了十年技术博客，我收获了什么
写技术博客这十年，让我感到最遗憾的事情是，有很多在我刚入行时候关注的觉得有价值的技术博客，作者都早已不再维护了，甚至域名呈现的内容都已经面目全非了。我还是希望在下一个十年我能继续走下去，对于我个人来说，好奇心在，表达欲就在。
今年刚好是我写技术博客的第十个年头。恰逢最近也有些所想、所感、所得，所以想把发自内心的对技术博客这件事唠叨几句。算是想到哪写哪，请见谅。
我的第一篇（姑且算是技术分类，但实际是我自己的做的一个软件介绍）技术博客发布于2010年，在我大二的时候，那时候的技术博客还托管在博客园(https://www.cnblogs.com/hh54188)上；之后在13年到14年左右的时候，为了熟悉 Node.js ，用 Node.js + MangoDB 写了一个内容管理的cms，并且部署在 heroku 上（后来因为没有续费，账号被删，源码也没有了）。最后因为维护成本过高，迁移到 github 的 jekyll 上，一直沿用至今。我博客的地址是 http://qingbob.com/， 但你可能更听说过它的另一个马甲——知乎专栏前端技术漫游指南( https://zhuanlan.zhihu.com/front-end)。
说真的我很好奇，在阅读这篇文章的你们有多少是冲着标题进来的，被“收获了什么”这个带有些神秘色彩的语句诱惑的不行，迫切想知道最终的答案是什么。
我不敢说收获是零，但如果我告诉你，写技术博客的这十年，我收获的可能并不会比你更多，你会不会很失望？
请允许我解释这件事，让我从一个工作的实际例子开始。
在加入项目的一年多的时间里，我负责的其中一项工作内容，是和前端代码中用到的一个第三方类库 Handsontable 斗智斗勇。这个类库据说能够承担海量级别的数据渲染。但是在我们的项目中，在有的场景里使用它渲染上千条数据的时就会导致浏览器呈现一种假死的状态，无法响应用户的请求。
我的工作就是需要找到它的瓶颈，修复它，还原它的能力。
在解决这个问题相当长的一段时间内，我都是抱着一种类似于刑侦探案，缉拿真凶的心态，试图找到性能问题背后的罪魁祸首。我认定真凶只有一个，一定存在某一处并不周正的代码拖累了整个页面的性能。
但结局是……这么说吧，好比其实是我找到了十处存在性能缺陷的代码，每处会导致 500 毫秒的延迟，单拎出来任意一个缺陷都在可以接收的范围之内。但是十处合并在一起拖累的就不只是5秒，而是会产生一加一大于二的效果。
说到底它还是一个写代码写糙了，或者说代码逐渐腐化了的问题，没什么大惊小怪的。但我总幻想着背后有什么惊天大阴谋，解决它就能带来质的飞跃。
哪有那么多事半功倍的好东西。
我想说的是，写技术博客也是一样，别指望它在某个时刻瞬间给你带技术上的突飞猛进，让你焕然一新。它和所有的“活”一样，通过长时间的实践，能让某些技巧变得娴熟，并锻炼你的一些能力。而所谓的“意外收获”？门都没有。我见过很多很厉害的、让我钦佩的程序员，他们也并非各个都写技术博客，但我相信他们有他们的方式训练自己。
所以我其实一直觉得，写技术博客是一种训练自己的过程。和反复地写代码，在上台前反复的练习演讲是一个道理。
对于我个人而言，我发现“发表是吸收的利器”。比如，你现在可以尝试把你今天学习到的知识马上向身边的小伙伴复述一遍，你会发现过程中你会对一些概念有些模糊，或者他会向你提出一些你没法立即回答的问题。这些都是值得再回过头去学习的知识点，而技术博客就是这么一个无声的小伙伴。
写作的迷思
即使是说训练，我觉得还是有一些写作过程中的迷思和陷阱想提醒大家，纯粹是我个人的经验。
首先需要明确的是，博客究竟是写给谁看的，读者还是我自己？
除非你在刻意运营公众号，需要迎合流量，否则一定是为你自己而写。
首先写作出发点就是你自己，只有当你有写作欲望的时候，才有可能下笔，才想把它尽善尽美的写好。
其次，也是更重要的是，读者关注的并非是你关注的。
分享一个很有意思的事情。有一段时间，我的技术文章会同步发布在知乎和掘金上。于是这部分文章有了三个视角：我看待它们，知乎的读者看待它们（点赞和收藏），和掘金的读者看待它们（点赞和收藏）。我发现，一般我个人花了最多时间去整理和学习知识之后写出来的最满意的文章，或者是我认为价值最高的文章，通常在这两个平台无人问津。而“快速入门”和“全解”之类的文章收藏量和阅读量却最高。
我理解他们，但是我觉得很可惜。
某一年我拍脑袋想出来的一个算法相关的idea，只花了三天时间就写完了，但这篇技术文章的点击率之高竟然成为了掘金的年度文章，让我哭笑不得。而且知乎和掘金的群体又不太一样，因为这篇文章在知乎上就没有任何的反响
你永远都不知道你的读者在想什么
第二，“写”这件事也是需要刻意提高的。
就算你工作了十年，但是你每天都在写hello world，你的技术也不会有任何的长进。
写文章也是一样，如果你只是为了写而写，习惯了在文章中贴大段大段的代码，抱着一种“自己去理解吧”的心态，而不是尝试用最简单的文字去引导和解释，你的写作水平和表达能力永远也不会有提升。
无论是在工作中还是文章里，我都反对不分原由的把文档、代码、或者是《XX权威指南》扔给某个人，然后让他自己去理解。这就好比你把一本汉语词典递给一个小学生让他自学语文。可以，但很难，也完全没有必要。
无论是在文字还是语言表达上，我习惯把我正在叙述的对象，想象为一名刚入门的程序员，或者只是一名有少许编程背景的QA同学，甚至是完全没有只是背景的 HR。然后思考我应该如何通过最通俗易懂的表述，让他们理解我想表达的概念。
甚至你还可以铺垫，卖关子，起承转合，控制预期等等，为你的文采添砖加瓦，但这一切都离不开刻意的练习。
这一套训练对口头表达同样有帮助。
第三，别怕不友好的评论
我不知道这是不是大家的问题，但这个是我的困恼。我的文章当然被怼过，我曾经因为被某个大V不友好的评论把文章的评论功能关闭了两年。
后来我对这件事的焦虑有所缓解和理解是基于两点：
我们很难通过文章评论的一来一回来表达我们想要表达的观点。别说是文章评论，在公司内部，我们在会议室里交流几个小时都不可能达成一致。在文章的背后，有我没有完全表达的背景、上下文或者大家对一件事的理解不同又没有办法统一。误解太正常了。
虽然“他”评论了，但是并不代表“他”有资格对你进行评论。也就是说，虽然我们有平等的网络地位，在现实生活中我们有平等的政治权力，但并不意味着在某些专业问题上，我们的评论有相同的分量。好比一个人不敢评论交响乐、油画，却又为什么敢评论脱口秀和相声呢，就因为大家都能说话是吗？你可以发出“地球是平的”的声音，大家也都能听到你的声音，但可能没人会把你的评论当一件事。回到技术文章上，至少你应该对你的技术文章是有自信的，对于质疑的声音，你要学会尝试去自行判断和理解。
- 相关阅读 -
是时候激活你的批判性思维了
点击【阅读原文】可至洞见网站查看原文&绿色字体部分的相关链接。
本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。